[Datenschleuder] [66]    Erfahrungen mit der zwangsweisen Einführung von verschlüsseltem http

Erfahrungen mit der zwangsweisen Einführung von verschlüsseltem http Erfahrungsbericht Zwangs-https Wie in der vorletzten DS verkündet, wurden im Herbst '98 für drei Monate alle Browser, die standardmäßig in der Lage sind, per https zu verbinden, zur Benutzung desselben auf www.ccc.de gezwungen. Einige interessante Probleme sind dabei aufgetaucht und einiges Herzleid wurde verursacht. Zwangsmaßnahmen sind ja sonst nicht so unsere Sache, auch wenn es schon Vorschläge gab, Verstöße gegen ein RFC mit Windowsbenutzung nicht unter zwei Jahren zu bestrafen. In diesem Fall erschien es gerechtfertigt, da Aufklärung zum Thema Public Key Cryptography und SSL not tat und immer noch tut, denn auch die neue Regierung scheint am SigG festzuhalten und die nötigen Hooks im BGB sollen im Laufe dieses Jahres beschlossen werden, womit eine elektronische Unterschrift auch ohne materielles Vertragsdokument Beweiskraft erlangt. Der zweite und nicht weniger wichtige Grund für möglichst viel verschlüsselten Traffic zu sorgen ist, um es den den Herren und Damen mit den großen Ohren möglichst schwer zu machen. Allerdings stellt sich die Frage, ob der Kampf gegen Zwang und Überwachung Zwangsmaßnahmen rechtfertigt. Nun, es hat mal jemand gesagt, daß das meiste Unrecht, im Glauben das Richtige zu tun, begangen worden ist. Die Umleitung war als Rewrite der URL in Abhängigkeit zum Browser implementiert, d.h. jeder, der mit einem sich als ╗Mozilla.*½ meldenden Browser ankam, wurde auf eine Seite mit Erklärungen und einem Link zum Download des CA-Certs (Certifying Authority) geleitet. Von dieser Seite waren auch noch weitere Hilfetexte angelinkt. Wer dies ausprobieren möchte, gehe zu http://www.ccc.de/~pluto/ssl/. Dort gibt es auch eine sehr übersichtliche Anleitung zum Einrichten der Umleitung. Weitere SSL-fähige Browser in die Umleitung mit einzuschließen war geplant, wurde aber nicht durchgeführt. Was es neues gibt, ist ein interner Bereich, der nur mit Vollwertkrypto und einem Client-Cert der cccCA erreichbar ist. Aus den ca. 500-600 Mails, die ich während der Umleitung bekommen habe, war herauszulesen, daß die meisten Surfer diese Umstellung nicht als Zwangsmaßnahme empfanden, sondern eher als eine Umstellung vom Default auf eine sinnvollere Alternative. Nur etwa einer von zehn, die die Aktion bewerteten, hat sich beschwert. Selbst User, die große Probleme mit https und dem per Hand nachzuladenden Server- und/oder CA-Cert hatten, waren in der überwiegenden Mehrheit voll des Lobes und begrüßten es als positiven Beitrag zum Thema. An technischen Problemen sind als erstes zwei Bugs im Internet Explorer zu nennen: Der erste betrifft das Abspeichern des CA-Certs, da hier als Default ╗Save to disk½ angegeben ist und dies manuell vor dem Öffnen auf ╗direkt öffnen½ umgestellt werden mus. Der Zweite ist schon gravierender, da der SSL / TLS-Standard reguläre Ausdrücke im Namen des Servers vorsieht (z.B. *.ccc.de, als DN), der IE aber in manchen Versionen nicht in der Lage ist, diese zu interpretieren und die Verbindung abbricht. Ein Bug des Netscape Navigators, welcher nach dem Laden des Certs manchmal die Fehlermeldung ╗Site not Found½ bringt ist noch unklar, scheint aber in neueren Versionen nicht mehr aufzutreten. Ein recht weit verbreitetes Problem sind Paket-Filtering-Firewalls, die den standard https Port (443) nicht durchlassen. Als prominentes Beispiel sei hier das BSI erwähnt, aber auch andere Firmen und Institutionen sind oder waren davon betroffen. Im allgemeinen hat eine Mail gereicht, um das Konfigurationsproblem zu beheben. Am ärgerlichsten war die Amerika Gedenk- Bibliothek, wo der Zugang von den dort aufgestellten öffentlichen Terminals nicht möglich war. Ein anderes Problem sind InternetcafΘs, da reichte allerdings ein Satz in der Umleitungs-Seite mit dem Hinweis, daß es reicht, das Cert des Servers ohne vorherigen Download des CA-Certs zu akzeptieren. Ob unsere Seiten auch noch in China gesehen werden konnten, ist nicht bekannt, aus Singapur gab es eine Fehlermeldung, aber mit dem Secure Proxy der städtischen Firewall konnte dann auch auf https zugegriffen werden. Durch die Umleitung wurden ca. 20-30% weniger Visits gezählt, allerdings lassen sich aus dem Vergleich der Zugriffszahlen nur Schätzungen herleiten, da hier noch zuviele weitere Faktoren mit im Spiel sind. Von allen Zugriffen benutzten nur ca. 5% einen Client mit waffenfähiger Krypto, sprich mit in voller Länge verschlüsselt übertragenen Session Keys. Aus den Erfahrungen mit diesem ersten Versuch lassen sich 2 hoch 4 mögliche Umleitungs- szenarien herleiten, hier die als Komponenten dargestellt sind: 1. Cert einer unbekannten CA, will heißen die User brauchen erst das Cert der CA. Dafür muß man einiges erklären, das ist aber auch der Vorteil, weil https klicken, ohne was mitzubekommen, kann man auf jeder eCommerce Site. 2. Cert einer bekannten CA. Keinen Ärger mit DAU's, keine Hilfe nötig, keine Anforderungen an den Intellekt der Surfer. Aber alles streßfrei verschlüsselt. 1. Das Cert beachtet bestimmte M$ Bugs (regexp im DN), dann gibt's weniger Ärger mit Mac Usern. Sprich kleinster gemeinsamer Nenner. 2. Das Cert ist standardkonform, aber nicht IE tauglich. I. Jede Schlüssellänge ist OK, also auch mit Exportbrowsern klickbar. Die NSA und ENFOPOL liest jedes Bit, weil nur 40 Bit des Session Keys verschlüsselt sind. II. Nur Vollwertkrypto wird akzeptiert. Alle schreien, weil man einen Domestic Browser (oder SSL-Proxy) braucht, aber die NSA oder ENFOPOL sehen nichts. Und man beugt sich nicht den amerikanischen Exportregulierungen. O. Alle Seiten können nur über https gesehen werden. X. Die Startseite und die FAQ werden unverschlüsselt übertragen. Variante 2 A I O/X benötigt keinerlei Hilfe zur Benutzung, ist aber langweilig. Variante 1 B I O war bei uns im Einsatz (ca. 30 G https Traffic, ca. 5-600 Mails) und hat imho gut funktioniert. Variante 1 B II X ist mein Liebling, allerdings reduziert diese den Traffic wg. nicht Klarkommen der Surfer ganz erheblich. Eignet sich nur für interne Seiten oder ein Publikum mit hohem Niveau / Sicherheitsbedürfnis. Variante 2 A I O haben wir gerade diskutiert, denke mal ein gangbarer Mittelweg ist 1 A I X. (Das ist Zufall! :) Gruß pluto@berlin.ccc.de

[Datenschleuder] [66]    Erfahrungen mit der zwangsweisen Einführung von verschlüsseltem http